一网打尽常见的软件测试策略

大家都清楚，测试资源、测试时间都是有限的，但是测试不能穷尽的，测试的空间是无限的，在有限的时间内、用有限的资源去探索无限的测试空间，的确需要策略。也就是说，在一个项目中，我们需要制定有效的测试策略，从而以有效的方式、方法完成测试任务，以最小的代价/成本去实现我们事先制定的测试目标，并把测试风险降到最低。测试策略描述了：

• 产品质量风险如何在测试层面得到缓解？
• 哪些类型的测试将被执行？
• 如何将测试过程划分为不同的测试阶段？
• 如何按不同的测试层次来分解测试任务？
• 哪些测试项要优先执行？
• 本项目中哪些入口/出口准则更适用？
• ......

了解什么是测试策略，还可以看我写的文章：究竟什么是软件测试策略？

之前，我还写过其它文章，介绍了最为常见的软件测试策略，如：

算是有了很好的铺垫，大家也有了理解的基础。今天，我就按照应用场景或测试过程的逻辑，把软件测试工作中常见的测试策略都列出来，供大家参考和使用。

1. 总体策略

1）基于风险的测试策略（Risk-based Test strategy，RBT），见之前的文章：ACTS：首屈一指的软件测试策略是什么？可以应用于任何地方，包括测试分析、测试设计、测试执行、测试结果评估等。

2）敏捷测试策略（从四象限模型改造而成），可以应用于项目中，也可以应用于组织这个层次，也可成为测试的方针政策（Test policy）。见之前的文章：2020年，我重新设计了新的敏捷测试四象限。

（来源：朱少民课程《全程软件测试》）

3）测试左移策略：基于V模型和缺陷来源/修复成本的理解，我们尽可能将测试活动前置，认真做好需求评审、设计评审和代码评审，及时发现需求问题、设计问题或代码问题，极大地降低测试风险，测试的代价也最小。在敏捷开发中，测试左移的策略就体现在全力推行ATDD（验收测试驱动开发）。

（来源：朱少民课程《全程软件测试》）

4）测试右移策略：由于今天软件更多时候是以一种服务（SaaS）存在，软件常常部署在自己的数据中心上，而不是在用户那里，这样我们完全可以控制产品的运行环境、获取产品运行状态或日志等数据，同时出现问题，我们往往能在很短时间内更新版本来修正缺陷。为了缩短测试周期、减少测试硬件资源的投入，我们就可以采用测试右移策略、灰度发布策略，将部分测试移到线上进行，包括在线性能测试、众测、用户参与测试等。有些测试，也只能通过在线方式更能反映真实情况，如A/B测试、全链路压测、混沌工程等。

来源：《敏捷测试：以持续测试支持持续交付》

5）分层测试策略：基于V模型和对软件产品结构的理解，我们可以针对软件的不同层次来开展工作，哪个层次更有利于发现问题就多投精力、早投精力；哪个层次更容易实现测试目标就侧重这个层次的测试工作。自动化测试 金字塔策略就具代表性。

（来源：朱少民课程《全程软件测试》）

2. 测试需求分析/计划采用的测试策略

6）启发式测试策略：见上一篇文章 测试中不可或缺的：启发式测试策略

7）基于模型的测试策略：如果被测系统的状态清晰、数量不多，或者输入、输出、过程和可能的行为能有效辨识，我们就可以构建有限状态机、活动图等测试模型，从而自动生成测试用例或测试脚本、测试数据，有利于未来测试设计的维护，提高测试效率。

（来源：朱少民课程《全程软件测试》）

8）因人而异的测试策略：在测试计划任务安排中，会根据每个人员的心态、能力、经验、性格等综合判断来安排任务，例如重点测试项、有较大风险的测试任务，一定安排给做事认真、有经验的测试人员。

9）按标准严格测试的策略：在一些性命攸关或使命攸关的行业（如核电行业、航空航天、汽车电子、医疗器械、银行、食品、药品等），有严格的测试流程和测试规范，测试计划的操作空间很小，入口/出口准则也很难调整，必须严格按照标准、规范执行。

3. 测试设计/执行采用的测试策略

10）持续测试策略：在一般商业软件开发中，大家更乐于采用敏捷、DevOps开发模式，在这样快速迭代、持续交付的环境下，更适合采用持续测试的策略，没有明显的测试阶段划分，更强调测试分析、设计和执行的融合，持续分析、持续设计和持续执行。

11）ET和TA有机结合的测试策略：新功能采用探索式测试（ET），已有功能的回归测试采用自动化测试（TA），详见6年前（2016年）我写的一篇文章：软件测试的一个新公式引起的思考。

12）交叉测试策略：这是测试执行中常用的测试策略，在测试执行的两轮中交换测试的模块。这项策略不仅缓解单个测试人员的思维局限性、测试不够充分等带来的风险，而且也有助于驱动测试质量的提升、测试人员的备份（经验积累）等。

13）80/20测试策略：最有风险的区域一般发生在测试范围中20%的区域，用户的80%时间只使用那20%的功能，所以测试会特别关注这20%的区域或功能特性。一般会将这20%功能（基本功能）的测试自动化，和CI/CD集成，只要有版本构建，这部分的脚本会执行，即通常说的BVT（build verification testing）。

14）组合测试策略：在测试用例设计中，当测试组合数很多时，这时就需要考虑组合测试策略，采用什么样的优化方法（如分类树、正交实验法、Pairwise法等）是合适的？采用什么样的组合强度是合适的？这就需要考虑对质量的测试要求、可用的测试时间等，选择合适的方法和组合强度（2～6中的一种）。

15）多种策略组合的回归测试策略：在回归测试中，如果选用单一的测试策略是比较危险的，一般会选用两种组合策略（RBT和基于操作剖面的策略）进行叠加，工作量可能会翻一倍，但总工作量近似等于40%，也低于全回归测试工作量（100%）。今天可能会采用精准测试的技术来优化回归测试集，但“精准测试” 其实不够准确，因为仅仅依赖代码覆盖率是有风险的，代码的依赖性不代表功能的依赖性、业务的依赖性。

16）两段论的测试策略：在测试前期采用逆向思维、RBT测试策略，尽可能发现缺陷，在测试后期，采用正向思维、基于操作剖面的策略，对主要功能进行验证，避免出现意想不到的问题。详见我的《全程软件测试（第3版）》。

4. 永无止境，不断制定出更好的测试策略

测试策略永无止境，因为测试的上下文（context）千变万化，甚至可以说，没有相同的上下文，每个测试项目、测试任务的上下文都不一样，团队不一样、行业不一样、产品不一样、功能特性不一样......根据不同的上下文就会制定不同的测试策略。概括起来，测试策略考虑的因素，包括下面这些项（但不局限于这些）：

• 软件所处的行业

• 软件研发所处的阶段

• 项目要求（项目目标、进度等）

• 开发模式
  

• 选用合适的质量标准
• 合适的测试目标
  
• 测试层次划分和利用
  
• 测试层次之间的关系（如先后次序）
• 测试阶段划分以及入口/出口条件
• 可以熟练运用的测试技术
• 不同的测试技术选择
• 测试中可以使用的工具
• 测试的自动化程度、水平
• 测试人员能力
• 开发是否有效配合、协同工作
• 测试资产及其复用性
• 测试环境状态
• 软件和测试工作产品的可重复使用性
• ......
  

根据这些因素，选择不同的测试方式、不同的测试方法、不同的测试技术/工具等，而且可以在不同的测试方式、方法、技术上分配不同的资源，先后次序安排也有讲究。例如，加强了静态测试（如代码评审、代码静态分析），那么动态测试（如基于JUnit的单元测试）就可以少做；多做API自动化测试，UI测试就可以少做；探索式测试起主导作用还是起辅助作用、甚至只使用探索式测试，是否采用自动化测试（并不是所有场合自动化测试都是有利的，例如一次性项目、试验性项目等）等等，都可以被看作测试策略。测试策略也是动态的，不是一成不变的，例如在测试计划初期确定的测试策略，在测试计划执行过程中会进行调整，因为情况发生了变化。

软件测试策略的制定的确需要智慧和经验，也依赖团队的头脑风暴和协作。制定出有效的测试策略，让测试质效合一，促进测试效能显著的提升，而且测试也变得更有趣，我们可以享受这样有趣的测试过程。更多体验，可以参考：如何最大化软件测试效能？（附分享的PPT）。

希望通过这篇文章，让大家彻底初步了解测试策略的价值、含义，未来能运用好已有的测试策略，制定出新的测试策略，持续提升测试的效能。

更好地运用测试策略，请参考《全程软件测试（第3版）》、《敏捷测试：以持续测试促进持续交付》。